A “C” or “C++”-Level API (hereinafter “C” Level), which is the native language and interface for a vast repository of core technologies from small software vendors and research laboratories, are unique to each designer. The designer of a text retrieval “C”-API will generally implement an interface that is completely different than a second inventor creating a “C”-level API for OCR.
Every “C”-level API is unique, both in its choice of API syntax as well as its method for implementing the syntax. Some API's consist of one or two functions that take parameters offering options for different features offered by the technology. Other APIs consist of hundreds of functions with few arguments, where each function is associated with a particular feature of the core technology. Other APIs provide a mixture of some features being combined with one function with many arguments, while other features are separated into individual function calls.
Without any constraints, each designer of a core technology chooses to implement his or her technology with an interface that is suitable to the subject or simply was the most expedient choice of the moment. Since there are no constraints, a “C”-level API has a totally unpredictable interface that can often be the hindrance to using the core technology.
Additionally, every API manages errors differently further complicating the problems described above. Some APIs return a consistent error code for each function. Error management in this case is very organized and manageable. Other APIs return error codes as one of the parameters passed to the function. There are APIs that mix the choice of error management and have some functions return an error code while other functions pass the error code as a parameter of a function. Errors can also be managed by a callback function, eliminating the need for passing any error code as part of the function. In some instances of a poorly implemented API the errors are not passed back at all.
Every engine, such as a text retrieval or an OCR (Optical Character Recognition) engine, has a unique interface. This interface is generally a “C”-level API (Application Program Interface). Further, an API can at any time be synchronous, asynchronous, manage one or more callbacks, require input, pass back output, carry a variety of different styles of functions, return values or not return values, and implement the unpredictable. This unpredictability in APIs further compounds the problem of developing a sane way of interfacing between components and APIs.
To date, because of the complexities of “C”-level APIs and components interfacing thereto, the only way to create a component out of an existing “C”-level API is to have an experienced programmer in the field to do the work. Humans can intelligently analyze an API, and create a component based on intelligent decisions and experiences. In most cases, the learning curve for understanding and integrating a new engine can be one man-month to several man-years and generally requires highly experienced “C” programmers. Requiring a human to perform the necessary work is costly, and subject to real-life human constraints.
Since there is no structure or format for implementing “C”-level APIs, the ability to automatically transform a unique API into a standard component would seem impossible, since that would take a nearly-human level of intelligence.
In addition, in spite of the continued automation of business processes, companies are increasing their paper use by 25-30% and spending up to 15% of their total budget on managing paper. Companies are often running dual processes—a computerized process along with the corresponding paper filing system—and paying an extraordinary price for it. Just a few examples will illustrate the problem: 1) accounting clerks are maintaining paper invoices with information that is also being re-keyed into accounting systems, 2) administrative assistants are filing incoming correspondence in cabinets for customers whose records are also being electronically maintained by contact management systems, 3) help desk operators are storing complaints sent in on paper while also tracking those complaints in a computerized system. Additional industry trends include the following:
For every $100M in increased revenues, a company will use 8.8 million additional pages of paper
The Document Management market is expected to grow at 30% per year
The digital device market is growing at 20% per year
Estimates show the web-based document imaging market growing at 50% per year
The digital device manufacturers, especially the copier companies, are heavily promoting the ability to connect their devices to networks, but have not been able to deliver an effective software solution to date.
Businesses continue to automate more processes, but managing the associated paper is often ignored, resulting in inefficiency and higher costs.
I have determined that a component factory, if it is to be truly automated or manually expedited, must be able to take any “C”-level API and transform it into a component.
I have also determined an efficient and workable design for an architecture to define the migration path for any “C”-level API into a component.
I have also determined that it is desirable to develop software tools for automatically generating reusable software components from core software technologies, thus making these software technologies available to a much larger user base.
I have further determined that it is desirable to design a distributed computer architecture and process for manually and/or automatically generating reusable software components. The computer architecture may be implemented using a client server and/or intranet and/or internet operating environments.
I have further determined that it is desirable to design a computer architecture and process for image viewing in a stand-alone and/or distributed environment. The computer architecture and process optionally uses a substantially uniform management layer in a stand-alone and/or distributed computing environment including, for example, client server and/or intranet and/or internet operating environments.
I have further determined that it is desirable to enable a typical PC user to add electronic paper processing to their existing business process.
I have further determined that it is desirable to enable software that manages paper so that it can be electronically and seamlessly copied in and out of devices and business applications (such as Microsoft Office, Microsoft Exchange, Lotus Notes) with an optional single-step Go operation.